home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / object-faq / part2 < prev    next >
Encoding:
Text File  |  1995-07-25  |  58.4 KB  |  1,304 lines

  1. Subject: Comp.Object FAQ Version 1.0.7 (10-27) Part 2/10
  2. Newsgroups: comp.object,comp.answers,news.answers
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Date: 29 Oct 1994 11:42:11 GMT
  5.  
  6. Archive-name: object-faq/part2
  7. Last-Modified: 10/27/94
  8. Version: 1.0.7
  9.  
  10. See APPENDIX E:60 for a CDROM with Internet FAQs.
  11.  
  12. A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on
  13. rtfm soon.  Contact cpplibs@trmphrst.demon.co.uk.  It contains anonymous ftp
  14. sites and commercial libraries and may be merged with this FAQ soon.
  15.  
  16. Many FAQs are also available from mail-servers, however most can be accessed by
  17. the rtfm mail-server.  Mail to mail-server@rtfm.mit.edu with help and index in
  18. the body with no leading spaces and on separate lines for more information.
  19.  
  20. Example Unix Command (will retrieve this FAQ in about 26 pieces (and growing)):
  21.   mail mail-server@rtfm.mit.edu
  22.   Subject:
  23.   send usenet/comp.object/*
  24.  
  25. There is also a great ftp site for sci.virtual-worlds on:
  26.   stein.u.washington.edu (140.142.56.1)
  27.           - home of sci.virtual-worlds, huge faq w/ great info!
  28.           - if unable to use try ftp.u.washington.edu
  29.           /public/virtual-worlds
  30.  
  31. [While VR may not be directly related to comp.object, it is most interesting!
  32.    - The Author]
  33.  
  34.  
  35. SECTION 2:  TYPING
  36. ==================
  37.  
  38. There are many definitions of type (and class and related concepts).  Many
  39. authors define the terms as applied by their particular approach or language,
  40. however we shall proceed in the face of this diversity.
  41.  
  42.   References
  43.     [Blair 89]          Some Typing Topics.
  44.     [Booch 91]          Small Section on Typing.
  45.     [Cardelli 85]       Discussion on Object-Oriented Typing.
  46.     [Gunter 94]         Theoretical Aspects of Object-Oriented Programming.
  47.     [Kim 89, ch1]       Discussion on Some Research Topics.
  48.  
  49.  
  50. 2.1)  What Is Polymorphism?
  51. ---------------------------
  52.  
  53. Polymorphism is a ubiquitous concept in object-oriented programming and is
  54. defined in many ways, so many definitions are presented from: Websters',
  55. Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh.
  56. Polymorphism is often considered the most powerful facility of an OOPL.
  57.  
  58. > Webster's New World Dictionary:
  59.  
  60. Polymorphism 1. State or condition of being polymorphous.  2. Cryall.
  61.   crystallization into 2 or more chemically identical but
  62.   crystallographically distinct forms.  3.  Zool., Bot. existence of an
  63.   animal or plant in several forms or color varieties.
  64.  
  65. polymorphous adj. having, assuming, or passing through many or various forms,
  66.   stages, or the like.  Also, polymorphic. [<Gk polymorphous multiform]
  67.  
  68.  
  69. > Author's Definition:
  70.  
  71. Polymorphism is the ability of an object (or reference) to assume (be replaced
  72. by) or become many different forms of object.  Inheritance (or delegation)
  73. specifies slightly different or additional structure or behavior for an object,
  74. and these more specific or additional attributes of an object of a base class
  75. (or type) when assuming or becoming an object of a derived class characterizes
  76. object-oriented polymorphism.  This is a special case of parametric
  77. polymorphism, which allows an object (or reference) to assume or become any
  78. object (possibly satisfying some implicit or explicit type constraints
  79. (parametric type), or a common structure), with this common structure being
  80. provided by base classes or types (subclass and subtype polymorphism,
  81. respectively).
  82.  
  83. "Poly" means "many" and "morph" means "form".  The homograph polymorphism has
  84. many uses in the sciences, all referring to objects that can take on or assume
  85. many different forms.  Computer Science refers to Strachey's original
  86. definitions of polymorphism, as divided into two major forms, parametric and
  87. ad-hoc.  Cardelli and Wegner followup with another classification scheme,
  88. adding inclusion polymorphism for subtyping and inheritance.
  89.  
  90.  
  91. > Strachey's Original Definition [Strachey 67]:
  92.  
  93. "Parametric polymorphism is obtained when a function works uniformly on a range
  94. of types; these types normally exhibit some common structure.  Ad-hoc
  95. polymorphism is obtained when a function works, or appears to work, on several
  96. different types (which may not exhibit a common structure) and may behave in
  97. unrelated ways for each type."  
  98.  
  99. Parametric polymorphism is also referred to as "true" polymorphism, whereas
  100. ad-hoc polymorphism isn't (apparent polymorphism).
  101.  
  102.  
  103. > Cardelli and Wegner's Definition [Cardelli 85]:
  104.  
  105. C+W refine Strachey's definition by adding "inclusion polymorphism" to model
  106. subtypes and subclasses (inheritance).  Strachey's parametric polymorphism is
  107. divided into parametric and inclusion polymorphism, which are closely related,
  108. but separated to draw a clear distinction between the two forms, which are then
  109. joined as specializations of the new "Universal" polymorphism.
  110.  
  111.                                  |-- parametric
  112.                  |-- universal --|
  113.                  |               |-- inclusion
  114.   polymorphism --|
  115.                  |               |-- overloading
  116.                  |-- ad hoc    --|
  117.                                  |-- coercion
  118.  
  119. Polymorphic Languages: some values and variables may have more than one type.
  120.  
  121. Polymorphic Functions: functions whose operands (actual parameters) can
  122.   have more than one type.  [...] If we consider a generic function to be
  123.   a value, it has many functional types and is therefore polymorphic.
  124.  
  125. Polymorphic Types: types whose operations are applicable to operands of more
  126.   than one type.
  127.  
  128. Parametric Polymorphism: a polymorphic function has an implicit or explicit
  129.   type parameter which determines the type of the argument for each
  130.   application of that function.
  131.  
  132. Inclusion Polymorphism: an object can be viewed as belonging to many different
  133.   classes that need not be disjoint; that is, there may be inclusion of
  134.   classes.
  135.  
  136. The two forms of "Universal Polymorphism", parametric and inclusion are closely
  137. related, but are distinct enough in implementation to justify separate
  138. classifications.
  139.  
  140. Parametric polymorphism is referred to as generics.  Generics can be syntactic,
  141. where each instantiation creates a specialized version of the code allowing
  142. fast running execution, but in a "true polymorphic system", only a single
  143. implementation is used.
  144.  
  145. On inheritance is subtype polymorphism:
  146. "Subtyping on record types corresponds to the concept of inheritance
  147. (subclass) in languages, especially if records are allowed to have functional
  148. components."
  149.  
  150. Author's Notes:
  151. Implicit parametric polymorphism can be implemented with type inferencing
  152. schemes [Aho 85].  ML is prototypical in providing this facility.
  153.  
  154. Inclusion polymorphism is common and is found in languages such as Simula,
  155. Ada-9x, C++, CLOS, Eiffel and etc. (subclass polymorphism).  Smalltalk also
  156. uses inclusion polymorphism; its used in declaring classes, and subclass
  157. polymorphism is used in practice but not enforced.  For inheritance, inclusion
  158. polymorphism specifies an instance of a subclass can appear wherever an
  159. instance of a superclass is required.  For subtyping (subtype polymorphism),
  160. the same applies because all operations required by the supertype are present
  161. in the subtype (subtype is subset of supertype).  Cardelli and Wegner view
  162. classes as sets of objects (resulting in subtype objects are a subset of
  163. supertype objects, or an extensional view), as contrasted with a feature based
  164. (intensional) approach (where subtypes are supersets of (contain) supertypes).
  165. MI provides an interesting example here, as it is set intersection with an
  166. extensional view and set union with an intensional view.  Details are left as
  167. an exercise for the reader.
  168.  
  169. Ada generics and C++ templates provide explicit syntactic generics.  While
  170. Ada may infer some actual generic parameters (operations) and C++ doesn't
  171. require explicit instantiation of its template functions, formal generic
  172. parameters must still be declared and many bodies are generated.
  173.  
  174. Inclusion polymorphism can refer to subtyping, or having at least as much or
  175. more than required.  Since derived classes can inherit structure and behavior
  176. from base classes, such inheritance is an example of inclusion polymorphism
  177. with respect to representation (subclassing).  An example of inclusion
  178. polymorphism with respect to assignment (and initialization, or replacement if
  179. viewed in an almost symbolic way) occurs when object types may be specified and
  180. assignment is based on actual object membership in that type (often of the CLOS
  181. is-a-member-of form in OO).  Emerald provides another example of an object-
  182. oriented language using inclusion polymorphism with respect to replacement;
  183. however, inclusion is with respect to subtyping only with abstract types
  184. ("bounded quantification" by C+W.  C+W's parameters are subtype polymorphic
  185. but lose the inherent type).  Any object possessing all required operations is
  186. acceptable and no inheritance relation is required (subtype polymorphism).
  187. They refer to this as "best-fitting" types [Black 86].  The original Trellis/
  188. Owl also had such a facility but with two separate inheritance hierarchies,
  189. although it was abandoned in favor of a single class-based approach for
  190. simplicity.  See also section 2.7.
  191.  
  192. [As inclusion polymorphism covers both subtype and subclass polymorphism,
  193.  perhaps IP could be further divided in C+W's above classification.]
  194.  
  195.  
  196. > Booch's Definition [Booch 91, p. 517]:
  197.  
  198. polymorphism  A concept in type theory, according to which a name (such as a
  199. variable declaration) may denote objects of many different classes that are
  200. related by some common superclass; thus, any object denoted by this name is
  201. able to respond to some common set of operations in different ways.
  202.  
  203. Booch also has several sections devoted to polymorphism.
  204.  
  205. [The author notes Booch's definition above is clearly in the context of
  206.  conventional, classical OO and subclass polymorphism.]
  207.  
  208.  
  209. > Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:
  210.  
  211. "Polymorphism" means the ability to take several forms.  In object-oriented
  212. programming, this refers to the ability of an entity to refer at run-time to
  213. instances of various classes.  In a typed environment such as Eiffel, this is
  214. constrained by inheritance: ...
  215.  
  216. [The Author notes Meyer has a following section 10.1.7 on Static Type,
  217.  dynamic type, which is relevant, but claims "... there is no way the type
  218.  of an object can ever change.  Only a reference can be polymorphic: ...".
  219.  Meyer is clear between the concept and the Eiffel realization in his
  220.  polymorphism definition above, but here neglects the "becomes" facility
  221.  as found in several dynamically typed OO languages such as Actors, CLOS,
  222.  Self and Smalltalk, which allows an object (and not just a reference) to
  223.  change its class.]
  224.  
  225.  
  226. > Stroustrup's Definition [Stroustrup 90, p. 209]:
  227.  
  228. The use of derived classes and virtual functions is often called "object-
  229. oriented programming".  Furthermore, the ability to call a variety of
  230. functions using exactly the same interface - as is provided by virtual
  231. functions - is sometimes called "polymorphism".
  232.  
  233. [The Author notes this is a functional view of polymorphism (as provided in
  234. C++).  [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
  235. but a newer template function is incomparably preferable, as implied in
  236. [Stroustrup 90, ch 14]]
  237.  
  238.  
  239. Rumbaugh's Definition [Rumbaugh 91, p. 2]:
  240.  
  241. "Polymorphism" means that the same operation may behave differently on
  242. different classes.
  243.  
  244.  
  245. 2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
  246. ----------------------------------------------------------------------
  247.  
  248. In C++, virtual functions provide polymorphism.  This is because a polymorphic
  249. object (pointer or reference (or such parameter)) is assignment compatible with
  250. any object of a derived class.  Is this polymorphism in itself?  Objects
  251. can take on objects of different forms (the derived classes), but of what use
  252. is it?  To make any difference, the differing forms must have some effect.  In
  253. dynamically typed languages, polymorphic objects are passed messages and will
  254. respond in whatever way the object has defined (usually starting from its most
  255. derived class and working its way up).  But for static objects, a virtual
  256. function is invoked.  This is the stored method from the derived class that
  257. overrode the virtual method from its base class, providing specialized behavior
  258. for the polymorphic object; and hence, polymorphism.  This common pure
  259. statically typed example is, of course, an example of inclusion polymorphism,
  260. subclass polymorphism to be more specific (see section 2.1).  Pure statically
  261. typed subtype polymorphism, as provided in Emerald, can be implemented
  262. similarly [Black 86].
  263.  
  264.  
  265. 2.3)  What Is Dynamic Binding?
  266. ------------------------------
  267.  
  268. Dynamic binding has two forms, static and dynamic.  Statically-typed dynamic
  269. binding is found in languages such as C++ (virtual functions) and Eiffel
  270. (redefinition).  It is not known which function will be called for a virtual
  271. function at run-time because a derived class may override the function, in
  272. which case the overriding function must be called.  Statically determining all
  273. possibilities of usage is undecidable.  When the complete program is compiled,
  274. all such functions are resolved (statically) for actual objects. Formal object
  275. usage must have a consistent way of accessing these functions, as achieved thru
  276. vtables of function pointers in the actual objects (C++) or equivalent,
  277. providing statically-typed dynamic binding (this is really just defining simple
  278. function pointers with static typechecking in the base class, and filling them
  279. in in the derived class, along with offsets to reset the receiver).
  280.  
  281. The run-time selection of methods is another case of dynamic binding, meaning
  282. lookup is performed (bound) at run-time (dynamically).  This is often desired
  283. and even required in many applications including databases, distributed
  284. programming and user interaction (e.g. GUIs).  Examples can be found in
  285. [Garfinkel 93, p80] and [Cox 91, pp 64-67].  To extend Garfinkels example with
  286. multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
  287. operation (along with parameters) to any object on the desktop, each of which
  288. handles the message in its own way (OO).  If an (application) object can cut
  289. many kinds of objects such as text and graphical objects, multiple-polymorphism
  290. comes into play, as many overloaded cut methods, one per type of object to be
  291. cut, are available in the receiving object, the particular method being
  292. selected based on the actual type of object being cut (which in the GUI case is
  293. not available until run-time).
  294.  
  295. Again, various optimizations exist for dynamic lookup to increase efficiency
  296. (such as found in [Agrawal 91] and [Chambers 92]).
  297.  
  298. Dynamic binding allows new objects and code to be interfaced with or added to
  299. a system without affecting existing code and eliminates switch statements.
  300. This removes the spread of knowledge of specific classes throughout a system,
  301. as each object knows what operation to support.  It also allows a reduction in
  302. program complexity by replacing a nested construct (switch statement) with a
  303. simple call.  It also allows small packages of behavior, improving coherence
  304. and loose coupling.  Another benefit is that code complexity increases not
  305. linearly but exponentially with lines of code, so that packaging code into
  306. methods reduces program complexity considerably, even further that removing
  307. the nested switch statement!  [Martin 92] covers some of these issues.
  308.  
  309.  
  310. 2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
  311. --------------------------------------------------------------------------
  312.  
  313. Yes (but be careful of context).  To use C++ terminology, an object (not
  314. a reference) is defined to be an instance of exactly one class (in classical
  315. OO), called its most derived class.  An object not directly contained in any
  316. other is called the complete object [Stroustrup 90].  An object is a member
  317. of several classes, including all of the classes its declared (or most derived)
  318. class inherits from.  With static typing and inclusion polymorphism based on
  319. class, if a polymorphic object (or reference) is made to refer to an object,
  320. that object must be a member of the polymorphic object's class.
  321.  
  322. This also provides a good example of differing definitions among object-
  323. oriented languages, since a member is defined as above in CLOS, but a member of
  324. a class is one of its instance variables in C++.
  325.  
  326.  
  327. 2.5)  What Is The Difference Between Static And Dynamic Typing?
  328. ---------------------------------------------------------------
  329.  
  330. Static typing refers to types declared in a program at compile-time, so no type
  331. information is available on objects at run-time.  Dynamic typing uses the
  332. inherent types of polymorphic objects, keeping track of the types of objects at
  333. run-time.  Statically typed dynamic binding is a compromise (usually
  334. implemented with tables of function pointers and offsets), and is how
  335. statically-typed OO languages provide polymorphism.  Some approaches provide
  336. both static and dynamic typing, sometimes with static typing providing type-
  337. safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
  338. [Mugridge 91].  See also section 2.3.
  339.  
  340. Static typing is more efficient and reliable, but loses power.  Typical
  341. restrictions include only allowing a common set of base class functions (or
  342. any common functions for the more general subtyping or parametric polymorphic
  343. cases) to be available on formal objects and a lack of multiple-polymorphism
  344. (see section 1.19), both of which are overcome with dynamic typing.
  345.  
  346. Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
  347. A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
  348. is even being considered for the C++ standard.  A similar facility to safe
  349. downcasting (historically known as type narrowing), the thrust of RTTI, can
  350. also be found in recent versions of Eiffel.
  351.  
  352. See section 3.4 for a categorization of common OO languages by type system.
  353.  
  354.  
  355. 2.6)  What Is This I Hear About ML And Functional Programming Languages?
  356. ------------------------------------------------------------------------
  357.  
  358. ML, Metalanguage, is a functional programming language with a strongly typed
  359. polymorphic type system [Wikstrom 87].  Russell (see Appendix E) is a more
  360. recent functional language and Haskell [Hudak 92] provides a more modern and
  361. "pure" example.  Section 2.5 discusses why static typing has less power/
  362. flexibility than dynamic typing and the same applies to ML (although see the
  363. appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
  364. 85] for a proper placement of ML's type system).  ML doesn't use inheritance
  365. for polymorphism; unlike OO languages, but provides the prototypical example of
  366. parametric polymorphism, so no inheritance is required.  This is "true" or
  367. "pure" statically (or strongly) checked parametric polymorphism, by Strachey's
  368. (and Cardelli and Wegner's) definitions.
  369.  
  370. Smalltalk is an example of a dynamically-typed language which does not check
  371. types during assignment (and hence for parameters) and therefore provides
  372. parametric polymorphism without static constraints (by Strachey's definition).
  373. However, Smalltalk's style uses inclusion polymorphism in practise and
  374. inheritance for subclassing (representation).
  375.  
  376.  
  377. 2.7)  What Is A Separation Between Type And Class (Representation)?
  378. -------------------------------------------------------------------
  379.  
  380. For a short answer:
  381.   Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
  382.   in OO.  Parametric polymorphism is a related concept where this is also true,
  383.   but is of a different flavor (and usually requires object attributes by use.
  384.   See also section 2.1).
  385.  
  386. A type can be considered a set of values and a set of operations on those
  387. values.  This can insure type-safe programming.  However, the representation of
  388. types (classes in OO) can be separated from the notion of type allowing many
  389. representations per type while still maintaining reasonable type-safety.
  390.  
  391. In many languages, a type has a single representation insuring all operations
  392. performed on that type are well defined (statically bound) and providing for
  393. efficiency by taking advantage of that representation wherever used.  In many
  394. OO languages, subclassing and dynamic binding provides for greater flexibility 
  395. by providing object specialization.  However, in many OO languages classes are
  396. used for assignment compatibility forcing an assigned object to inherit
  397. (transitively) from any polymorphic object's class (inclusion polymorphism
  398. based on class, or subclass polymorphism).  This insures all operations to be
  399. performed on any polymorphic object are satisfied by any replacing objects.
  400. This also insures all types share a common representation, or at least a
  401. common base interface specification.
  402.  
  403. By separating type from class, or representation (or perhaps separating class
  404. from type, by the aforementioned definition of type), a replacing object must
  405. satisfy the operations or type constraints of a polymorphic object (subtype
  406. polymorphism) but are not required to do to do so by an inheritance relation
  407. (subclass polymorphism), as is typical in most OOPLs.  Dropping this
  408. restriction is somewhat less type-safe, because accidental matches of method
  409. signatures can occur, calling for greater care in use.  [Black 86] discusses
  410. this issue in Emerald.  The same issue arises in parametric polymorphism
  411. (generics/templates), as any method matching a required signature is accepted,
  412. calling for careful matching of actual and formal generic parameters.  The
  413. difference between static and dynamic binding in OO and dynamic binding and
  414. subtyping seems similar.  A possible loss of semantic integrity/similarity is
  415. contrasted with greater power.
  416.  
  417. It is possible to specify desired abstract properties of type specifications
  418. with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
  419. This helps to insure the semantic integrity of replacing objects and their
  420. behavior.  [Liskov 93] provides a recent exposition.
  421.  
  422. Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
  423. similar to subtype polymorphism; however, ACs require type compatible classes
  424. to inherit from them, providing a subclass polymorphism facility, and ACs can
  425. also specify representation.  Subtyping is therefore most useful to avoid
  426. spreading knowledge of classes throughout a system, which is a high priority
  427. for loosely coupled modules and in distributed programming [Black 87].
  428.  
  429. The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
  430. [Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
  431. Signatures), Sather (originally Eiffel-based), and an Eiffel superset
  432. [Jones 92] are all examples of OO systems providing subtype polymorphism.
  433. Functional languages such as ML, Russell, and Haskell provide a separation with
  434. pure parametric polymorphism (as is also commonly found in OO languages in
  435. addition to inclusion polymorphism).
  436.  
  437. See also [Cook 90], "Inheritance Is Not Subtyping", for a formal approach.
  438.  
  439.  
  440. 2.8)  What Are Generics And Templates?
  441. --------------------------------------
  442.  
  443. Short Answer: Parametric Polymorphism (although various implementations
  444.               provide various subsets).
  445.  
  446. Generics (or Templates in C++) refer to the ability to parameterize types
  447. and functions with types.  This is useful for parameterized classes and
  448. polymorphic functions as found in languages such as Ada, C++, Eiffel, and
  449. etc., although these are "syntactic" or restricted forms [Cardelli 85].
  450. Generics are orthogonal to inheritance, since types (and classes)
  451. may be generically parameterized.  Generics provide for reusability in
  452. programming languages.  An example is a Stack with a generically
  453. parameterized base type.  This allows a single Stack class to provide
  454. many instantiations such as a Stack of ints, a Stack of any fundamental
  455. or user defined type, or even a Stack of Stacks of ...  Another example is
  456. a polymorphic sort function taking a base type with a comparison operator.
  457. The function can be called with any type (containing a comparison operator).
  458. See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
  459. 93] for examples in C++.
  460.  
  461. While generics have many advantages, typical limitations include a static
  462. nature, which is an advantage for strong typechecking but a potential
  463. disadvantage when causing dynamic compilation (leading to a time/space
  464. efficiency tradeoff), and sources can cause inlining and create source code
  465. dependencies and expand code size (unlike a single-body or "true"
  466. parametrically polymorphic implementation.  Generics can also be viewed as a
  467. special case of type variables.
  468.  
  469. Functions are typically generic in statically-typed parametrically-polymorphic
  470. languages.  One such popular functional language is ML, in which all functions
  471. are generic.  Russell and Haskel are more modern variants (references are
  472. forthcoming, however see APPENDIX E).
  473.  
  474.  
  475. SECTION 3:  GENERAL
  476. ===================
  477.  
  478.   References:   (many more are to come)
  479.     [Coplien 92]    Covers C++, symbolic, exemplar (single-hierarchy), etc.
  480.     [Kim 89]        Covers many OO systems.
  481.  
  482.  
  483. 3.1)  What Is The "Classical" Object-Oriented Paradigm?
  484. -------------------------------------------------------
  485.  
  486. This refers to the usual class and object model.  Its any 2+ level system
  487. as described in section 1.4.  See also [Coplien 92].
  488.  
  489.  
  490. 3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
  491. --------------------------------------------------------------------
  492.  
  493. See [Kim 89, ch 1,3].
  494.  
  495. This is the 1 Level System as Described under Meta-Classes.  Delegation refers
  496. to the delegating of responsibility and can be applied to inheritance.  When a
  497. derived class does not have a desired attribute, it "delegates" responsibility
  498. to one of its base classes.  In delegation systems, each object has a delegate
  499. list instead of a parent list. Thus, delegation's primary emphasis is 
  500. on message passing where an object could delegate responsibility of a message
  501. it couldn't handle to objects that potentially could (its delegates).  Any
  502. object can be added to the delegate list, giving dynamic inheritance (of a
  503. sort).  Typically, delegation and prototyping languages also have "part
  504. inheritance" in which fields and methods can be added and deleted from objects.
  505. This makes for easy "prototyping", which allows for objects to be constructed
  506. piece by piece at run-time, although the term "prototyping" in the context of
  507. delegation languages usually refers to objects serving as prototypes for
  508. object instantiation, or exemplars.
  509.  
  510. Next's NextStep OS provides delegation using Objective-C, providing an example
  511. of delegation in a class-based language [Garfinkel 93].
  512.  
  513.  
  514. 3.3)  Are There Any Other Object-Oriented Paradigms?
  515. ----------------------------------------------------
  516.  
  517. There are many alternatives in OO.  Emerald/Jade ([Black 86] and [Raj 89])
  518. provides one, where inheritance is replaced with a roughly equivalent form
  519. where reuse occurs at a finer degree of granularity - method and instance
  520. variables - with subtype polymorphism making up the difference.
  521.  
  522. CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
  523. distinguish a receiver, but packages can help make up the difference.
  524.  
  525. Object Specialization [Sciore 89] is an example of a hybrid approach between
  526. delegation and classical systems, where parent classes have an extra level
  527. of indirection and inheritance hierarchies are specified on a per object/class
  528. basis.
  529.  
  530.  
  531. 3.4)  What Are The Major Object-Oriented Programming Languages Today?
  532. ---------------------------------------------------------------------
  533.  
  534. Statically-Typed:
  535.   Add 1 To Cobol giving Cobol with Objects.
  536.   C++
  537.   Classic-Ada
  538.   Dragoon
  539.   Emerald/Jade
  540.   Object Pascal
  541.   Trellis/Owl
  542.  
  543. Dynamically-Typed:
  544.   Actors Languages
  545.   C+@
  546.   Flavors
  547.   Self
  548.   Smalltalk
  549.  
  550. Both:
  551.   Actor
  552.   Ada-9x
  553.   BETA
  554.   C++ (With RTTI)
  555.   Cecil
  556.   CLOS
  557.   Eiffel
  558.   Modula-3
  559.   Objective-C
  560.   Sather
  561.  
  562.  
  563. 3.5)  What Are Object-Oriented Databases And Persistence?
  564. ---------------------------------------------------------
  565.  
  566. See also Appendices B and E and the comp.database.object newsgroup.
  567. Refs to be included in future FAQs.
  568.  
  569. Object-Oriented Databases are databases that support objects and classes.  They
  570. are different from the more traditional relational databases because they allow
  571. structured subobjects, each object has its own identity, or object-id (as
  572. opposed to a purely value-oriented approach) and because of support for methods
  573. and inheritance.  It is also possible to provide relational operations on an
  574. object-oriented database.  OODBs allow all the benefits of object-orientation,
  575. as well as the ability to have a strong equivalence with object-oriented
  576. programs, an equivalence that would be lost if an alternative were chosen, as
  577. with a purely relational database.
  578.  
  579. Another way of looking at Object-Oriented Databases is as a persistent object
  580. store with a DBMS.
  581.  
  582. Persistence is often defined as objects (and their classes in the case of
  583. OODBs) that outlive the programs that create them.  Object lifetimes can be
  584. viewed as a hierarchy, with locals/automatics having the shortest default
  585. lifetime and objects stored indefinitely in an OODB (which are persistent)
  586. having the longest.  Persistent object stores do not support query or
  587. interactive user interface facilities, as found in a fully supported OODBMS.
  588.  
  589. Appendix B also contains references for object-oriented interfaces to
  590. relational databases and see APPENDIX E, Papers, Persistent Operating Systems.
  591.  
  592. From the net:
  593. From: dbmsfacts@aol.com (DBMSfacts)
  594. Subject: ODMG Gopher and Web Addresses
  595. Date: 24 Oct 1994 13:10:02 -0400
  596.  
  597. The Object Database Management Group (ODMG) has set up Gopher and Web
  598. Servers at the following addresses:
  599.  
  600.   Gopher:  gopher.odmg.org, port 2073
  601.   WWW:  http://www.odmg.org:3083
  602.  
  603. These are still under construction.  What you can find right now are
  604. addresses and contact information for ODBMS vendors, ODMG membership
  605. information, updates to Release 1.1 of The Object Database Standard:
  606. ODMG-93 along with ODL lex and yacc files.  In the future, we will be
  607. adding more links to related sites, bibliographies, and a FAQ for ODBMSs. 
  608.  
  609. If you cannot access these servers, but would like information on the
  610. ODMG, send an email message to info@odmg.org and you will receive an
  611. automated reply.
  612.  
  613. Doug Barry
  614. ODMG Executive Director
  615.  
  616.  
  617. 3.6)  What Are Object-Oriented Operating Systems?
  618. -------------------------------------------------
  619.  
  620. Refs to be included in future FAQs.  See also Appendix E.
  621.  
  622. Object-Oriented Operating Systems provide resources through objects, sometimes
  623. all the way down to to the machine (OO architectures are found at the bottom).
  624. They are almost always distributed systems (DOS or DPOS), allowing objects to
  625. be passed freely between machines.  They are typically capability-based since
  626. objects, and hence system resources, can only be accessed if a capability to
  627. them is available to programs.
  628.  
  629. Here are some abstracts taken from several postings to the net.  This list is
  630. by no means exhaustive.
  631.  
  632. Apertos (Meta-Object-based Mikro-Kernel.  See Appendix E, Papers:28)
  633. Chorus Micro-kernel (written in C++, COOL, See Appendix E, Papers:63)
  634. Choices (research OS, UofI, C++, supports SVR4, See Appendix E, Papers)
  635. GEOS    (GeoWorks', written in Object Assembler, OO superset of 8086) 
  636. Mach    (CMU, supports BSD 4.3, really message-based)
  637. NachOS  (written in C++, OS teaching/learning OS)
  638. Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
  639. Peace    (OO family-based parallel OS, See Appendix E, General)
  640. SOS
  641. Spring      (Sun, written in C++)
  642. PenPoint OS (Go, written in C++)
  643.  
  644. For the Spring Papers (free), Contact:
  645.   Sun Microsystems Laboratories, Inc.
  646.   M/S 29-01
  647.   2550 Garcia Avenue
  648.   Mountain View, CA USA  94043
  649.  
  650. See also APPENDIX E, PAPERS, Persistent Operating Systems entry.
  651.  
  652. From: whitney@oberon.Meakins.McGill.CA ()
  653.  
  654. Insight ETHOS: On Object-Orientation in Operating Systems
  655. ISBN 3 72811948 2
  656.  
  657. This thesis covers the design of an extensible object-oriented 
  658. operating systems. The language used was Oberon-2. It includes
  659. a generalization of the Rider/Carrier principle, Object Directories
  660. as well as basic OS issues such as memory, file, tasking management. 
  661. It covers extensible objected-oriented programming from hardware up.
  662. It reviews other designs such as Clouds and Choices which where written
  663. It reviews other designs such as Clouds and Choices which where written
  664. on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
  665. ETHOS was implemented as an operating system for the Ceres computers
  666. at the ETH. 
  667.  
  668.  
  669. 3.7)  What Are The Current Object-Oriented Methodologies?
  670. ---------------------------------------------------------
  671.  
  672. Here is a list of OOSE Methodologies:
  673.  
  674.   Berard                        [Berard 93]
  675.   BON                           [Nerson 92]
  676.   Booch                         [Booch 94]
  677.   Coad/Yourdon                  [Coad 91]
  678.   Colbert                       [Colbert 89]
  679.   de Champeaux                  [de Champeaux 93]
  680.   Embley                        [Embley 92]
  681.   EVB                           [Jurik 92]
  682.   FUSION                        [Coleman 94]
  683.   HOOD                          [HOOD 89]
  684.   IBM                           [IBM 90,91]
  685.   Jacobson                      [Jacobson 92]
  686.   Martin/Odell                  [Martin 92]
  687.   Reenskaug (OOram, was OORASS) [Reenskaug 91]
  688.   ROOM                          [Selic 94]
  689.   Rumbaugh et al.               [Rumbaugh 91]
  690.   Shlaer and Mellor             [Shlaer 88 and 92]
  691.   Wasserman                     [Wasserman 90]
  692.   Winter Partners (OSMOSYS)     [Winter Partners]
  693.   Wirfs-Brock et al.            [Wirfs-Brock 90]
  694.  
  695. Further Ideas And Techniques:
  696.   Meyer                         [Meyer 88]
  697.   Stroustrup                    [Stroustrup 91]
  698.  
  699. See APPENDIX D for CASE systems supporting these methodologies (several from
  700. the originators themselves).
  701.  
  702. See also section 1.21 for a discussion on OOA/OOD and etc.
  703.  
  704. Summaries and comparisons will be provided in future FAQs.  Suggestions for
  705. inclusion of other major or new methodologies should be sent to the FAQ author.
  706.  
  707. Here are some comparison studies posted to the net:
  708.  
  709. Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of 
  710. Five Object Oriented Development Methods, Research report, HP Laboratories, 
  711. June 1991
  712.  
  713. de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
  714. oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
  715. 21-32.  Vol.5, No. 1, 3/4-92
  716.  
  717. Fichman R.G. & Kemerer C.F.  OO and Conventional Analysis and Design
  718. Methodologies.  Computer, Oct 1992, Vol 25, No. 10, p 22-40
  719.  
  720. Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
  721. and Design Methods - Comparison and Critique.  IEEE-Comp, Oct, 1992, pp 22-39.
  722. OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
  723. Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
  724. Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
  725. Booch OOD, Wirfs-Brock responsibility-driven design.
  726.  
  727. Hong, S., van den Goor, G., and Brinkkemper, S.  A Comparison of Object-
  728. oriented Analysis and Design Methods. Working paper, Computer Information
  729. Systems Department, Georgia State University, Atlanta USA, 1992, 12 pages. To
  730. appear in the Proceedings of the 26th Hawaiian international conference on
  731. System Sciences, IEEE Computer Science Press.
  732.  
  733. Hong, S., van den Goor, G., Brinkkemper, S. A Formal Approach to the Comparison
  734. of Object-Oriented Analysis and Design Methodologies, Hawaii International 
  735. Conference on System Sciences (HICSS) (IEEE Computer Society Press, Hawaii)
  736. 1993, Vol. IV, pp. 689-698.  Summary of [van den Goor et.al., 1992] below.
  737.  
  738.   Order procedure:
  739.   Available from the authors at cisssh@gsusgi2.gsu.edu or sjbr@cs.utwente.nl.
  740.   The authors, regretfully, cannot supply ftp, postscript, TEX, or 
  741.   whatsoever.
  742.  
  743. Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
  744. Analysis and Design.  CACM/September 1992/Vol.35, No.9, pp35.
  745.  
  746. [Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
  747. Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
  748. Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.
  749.  
  750. Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
  751. Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.
  752.  
  753. UNICOM. Approaches to Object-Oriented Analysis and Design.
  754. tel: l 44 895 256 484. Ask the TOC and have a look at it.
  755.  
  756.  
  757. Also commercially available:
  758.  
  759. An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
  760. J. Cribbs, C Roe, S. Moon
  761. SIGS Books
  762. (212) 274-0640
  763. $149.
  764.  
  765. Object-Oriented Methodology Comparison Study (10 methodologies)
  766. Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
  767. Shlaer/Mellor, Wirfs-Brock.  Also contains refs to several previous studies.
  768. Berard Software Engineering
  769. 101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
  770. Contact Person: Jim Youlio
  771. Phone:        301-417-9884
  772. Fax:          301-417-0021
  773. email:        info@bse.com
  774.  
  775. [van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper,
  776. A Comparison of Six Object-oriented Analysis and Design Methods. Report
  777. Center of Telematics and Information Technology, University of Twente,
  778. the Netherlands, and Computer Information Systems Department, Georgia
  779. State University, Atlanta, USA, 1992, 163 pages, US$ 70.
  780.  
  781. This report gives an in-depth analysis of six generally accepted
  782. O-O methods, that are available in textbooks. The background, steps,
  783. concepts, notations, and specification techniques of the methods
  784. are extensively compared.
  785.  
  786. The six methods are:
  787. -  Object Oriented Analysis & Object Oriented Design (OOA/OOD) of Coad &
  788.       Yourdon (1991)
  789. -  Designing Object Oriented Software (DOOS) of Wirfs-Brock et.al. (1990)
  790. -  Object Modelling Technique (OMT) of Rumbaugh et.al. (1991)
  791. -  Object Oriented Systems Analysis (OOSA) of Shlaer & Mellor (1988)
  792. -  Object Oriented Design with Applications (OODA) of Booch (1991)
  793. -  Object Oriented Analysis and Design (OOAD) of Martin & Odell (1992).
  794.  
  795. The comparison is performed by meta-modelling, resulting into detailed
  796. information on the concepts of the methods (in EER notation) and on the
  797. steps of the procedure of the methods (in Task Diagrams). Extensive
  798. comparison tables of steps, concepts, techniques are included. Mappings of
  799. the methodical concepts to the constructs of programming languages (C++,
  800. Objective-C, Smalltalk-80, Object Pascal en CLOS) are given. A small
  801. test case illustrates the application of the methods.
  802.  
  803. Order procedure:
  804. Those who want to order the complete report (163 pp.) can order one by
  805. specifying their postal address in an e-mail (sjbr@cs.utwente.nl) or fax
  806. (+31.53.33.9605) attn. Sjaak Brinkkemper. The report will be send within
  807. two weeks with an invoice for US$ 70. (seventy dollar; including shipping,
  808. excl VAT).
  809.  
  810.  
  811. 3.8)  What Is the OMG/OMA/ORB/CORBA?
  812. ------------------------------------
  813.  
  814. Contents:
  815.   (3.8.1)  Contact Information
  816.   (3.8.2)  OMG Summary
  817.   (3.8.3)  Mail Server Access
  818.   (3.8.4)  OMG Publications
  819.              - First Class (Bi-Monthly Newsletter)
  820.              - Object Management Architecture Guide (OMA)
  821.              - The Common Object Request Broker: Arch. and Spec. (Corba)
  822.              - Pricing
  823.   (3.8.5)  Implementations (Brief)
  824.   (3.8.6)  Implementation Descriptions
  825.   (3.8.7)  Books, Articles, And Literature
  826.  
  827.  
  828. 3.8.1  Contact Information
  829. __________________________
  830.  
  831. Contact Person: Richard Soley (technical director) soley@omg.com
  832.  
  833. FTP Sites: 
  834.   omg.org:pub/*
  835.   omg.org:pub/NEC_DII/93-1-2.tar...            *CORBA (DII) (corba.ps.Z)
  836.   omg.org:pub/OMG_IDL_CFE_1.2/bin*              idl.SunOS4.x, idl.Solaris2.x
  837.   claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec
  838.  
  839. Headquarters:                            Marketing Office:
  840.   492 Old Connecticut Path                 3823 Birchwood Drive
  841.   Framingham, MA 01701                     Boulder, CO  80304
  842.   Tel: 508-820-4300                        Tel: 303-444-8129
  843.   Fax: 508-820-4303                        Fax: 303-444-8172
  844.  
  845.  
  846. 3.8.2  OMG Summary
  847. __________________
  848.  
  849. From: soley@emerald.omg.ORG (Richard Mark Soley)
  850. Subject: OMG
  851.  
  852. In answer to your general question about the OMG, here's a brief overview.
  853. Feel free to call, fax or email for more information.
  854.  
  855.         -- Richard Soley
  856.            Vice President & Technical Director
  857.            Object Management Group, Inc.
  858.            and coincidentally, MIT '82, SM '85, PhD '89 (EECS)
  859.  
  860. The Object Management Group (OMG) is an international software industry
  861. consortium with two primary aims:
  862.  
  863. (*) promotion of the object-oriented approach to software engineering
  864.     in general, and
  865.  
  866. (*) development of command models and a common interface for the development
  867.     and use of large-scale distributed applications (open distributed
  868.     processing) using object-oriented methodology.
  869.  
  870. In late 1990 the OMG published its Object Management Architecture
  871. (OMA) Guide document. This document outlines a single terminology for
  872. object-oriented languages, systems, databases and application
  873. frameworks; an abstract framework for object-oriented systems; a set
  874. of both technical and architectural goals; and an architecture
  875. (reference model) for distributed applications using object-oriented
  876. techniques.  To fill out this reference model, four areas of
  877. standardization have been identified:
  878.  
  879. 1) the Object Request Broker, or key communications element, for
  880.    handling distribution of messages between application objects in
  881.    a highly interoperable manner;
  882.  
  883. 2) the Object Model, or single design-portability abstract model for
  884.    communicating with OMG-conforming object-oriented systems;
  885.  
  886. 3) the Object Services, which will provide the main functions for
  887.    realising basic object functionality using the Object Request Broker -
  888.    the logical modeling and physical storage of objects; and
  889.  
  890. 4) the Common Facilities will comprise facilities which are useful in
  891. many application domains and which will be made available through OMA
  892. compliant class interfaces.
  893.  
  894. The OMG adoption cycle includes Requests for Information and
  895. Proposals, requesting detailed technical and commercial availability
  896. information from OMG members about existing products to fill
  897. particular parts of the reference model architecture.  After passage
  898. by Technical and Business committees to review these responses, the
  899. OMG Board of Directors makes a final determination for technology adoption.
  900. Adopted specifications are available on a fee-free basis to members and
  901. non-members alike.
  902.  
  903. In late 1991 OMG adopted its first interface technology, for the Object
  904. Request Broker portion of the reference model.  This technology, adopted
  905. from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
  906. HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
  907. Design Inc. includes both static and dynamic interfaces to an inter-
  908. application request handling software "bus."
  909.  
  910. Unlike other organizations, the OMG itself does not and will not
  911. develop nor sell software of any kind.  Instead, it selects and promulgates
  912. software interfaces; products which offer these interfaces continue to be
  913. developed and offered by commercial companies.
  914.  
  915. In order to serve OMG membership interested in other object-oriented systems
  916. arenas besides the distributed system problem, the Group supports Special
  917. Interest Groups for discussion of possible standards in other areas.  These
  918. groups at present are:
  919.  
  920.         1) Object Oriented Databases;
  921.         2) OO Languages;
  922.         3) End-User Requirements;
  923.         4) Parallel Processing;
  924.         5) Analysis & Design Methodologies;
  925.         6) Smalltalk; and
  926.         7) Class Libraries.
  927.  
  928. Any company, university/research institution or individual, whether
  929. end-user or vendor, can become a member of this body.  Administrative
  930. details are given at the end of this paper.
  931.  
  932.  
  933. 3.8.3  Mail Server Access
  934. _________________________
  935.  
  936. Information via Mail Server:
  937.   Send the following commands in a letter to the mail server.
  938.  
  939. mail omg_server@omg.org
  940. help                             (how to use file server)
  941. index                            (return a list of all available files)
  942. get <file>                       (get files returned by  index)
  943. log <info>                       (logs info on server)
  944. address <e-mail address)         (use this address instead of sender)
  945. list <directory> [match]         (index a directory, pattern 'match' files)
  946. size <segment size>              (max file size to send)
  947.  
  948. list mail
  949. list docs
  950. get docs/doclist.txt             
  951. get docs/91-12-1.ps               CORBA spec [although it looks a little old]
  952.  
  953.  
  954. Recommended (from the net):
  955.  
  956. mail omg_server@omg.org
  957. Subject: 
  958. help
  959. index
  960. list
  961. list mail
  962. list docs
  963. get docs/doclist.txt
  964.  
  965.  
  966. 3.8.4  OMG Publications
  967. _______________________
  968.  
  969. Below is from omg.org:pub/CORBA
  970.  
  971.  
  972. > First Class (Bi-Monthly Newsletter)
  973.  
  974. First Class is OMG's non-commercial bi-monthly 28-page
  975. newsletter. First Class provides current information on Object
  976. Technology developments, both technically and commercially. First
  977. Class offers an open editorial forum on numerous Object
  978. Technology topics and issues.  This publication features
  979. commentaries from software industry leaders, informative user
  980. case histories, OT training information and the latest object-
  981. oriented product announcements.  All OMG activities and the
  982. ongoing development of the Object Management Architecture are
  983. regularly reported.
  984.  
  985.  
  986. > Object Management Architecture Guide (OMA)
  987.  
  988. The members of the OMG have a shared goal of developing and using
  989. integrated software systems.  These systems should be built using
  990. a methodology that supports modular production of software;
  991. encourages reuse of code; allows useful integration across lines
  992. of developers, operating systems and hardware; and enhance long-
  993. range maintenance of that code.  As an organization, OMG believes
  994. that the object-oriented approach to software construction best
  995. supports their goals.  The OMA publication outlines the
  996. groundwork for technology response to Request for Proposals (RFP)
  997. and the adoption of specifications.
  998.  
  999.  
  1000. > The Common Object Request Broker: Arch. and Spec. (Corba)
  1001.  
  1002. The CORBA, as defined by the OMG's Object Request Broker (ORB),
  1003. provides the mechanisms by which objects transparently make
  1004. requests and receive responses. The ORB provides interoperability
  1005. between applications on different machines in heterogeneous
  1006. distributed environments and seamlessly interconnects multiple
  1007. object systems. The Common Object Request Broker Architecture and
  1008. Specification described in this published document is a self-
  1009. contained response to the Request for Proposals (RFP) issued by
  1010. the ORB Task Force of the OMG.
  1011.  
  1012. > Pricing
  1013.  
  1014. [Here's why you don't see the specifications posted to the net or available via
  1015.  ftp!  These are from the list of literature and periodicals listed in
  1016.  omg.org:pub/CORBA]
  1017.  
  1018. o I would like a one year subscription to First Class
  1019.     ______ for $40 U.S.,  ______ for $50 outside U.S.
  1020.  
  1021. o I would like to order  ______ copy(s) of the Object Management
  1022.   Architecture (OMA) Guide for $50 each.
  1023.  
  1024. o I would like to order  ______ copy(s) of the CORBA for $50 each.
  1025.  
  1026. o [Combinations]
  1027.  
  1028. Contact documents@omg.org or omg_documents@omg.org for more of the same...
  1029.  
  1030.  
  1031. 3.8.5  Implementations (Brief)
  1032. ______________________________
  1033.  
  1034. > DEC ObjectBroker Version 2.5  (Version 2.1 was ACA)
  1035.   Full implementation of OMG CORBA 1.1.  Digital's ObjectBroker is a 100 %
  1036.   compliant implementation of CORBA and is available on these  platforms:
  1037.   IBM AIX, IBM MVS(port in progress), HP-UX, Macintosh, MS-Windows 3.1, NT,
  1038.   OSF/1, SunOS, ULTRIX, Digital  VAX/VMS, Digital OpenVMS
  1039. Contact:
  1040.   Andrew Comas
  1041.   comas@nyo.dec.com  (212) 856-2507
  1042.   Digital Equipment Corporation.
  1043.   ObjectBroker
  1044.   110 Spit Brook Road
  1045.   Nashua, New Hampshire  03062-2698
  1046.  
  1047. > HP ORB Plus and HP Distributed Smalltalk
  1048.    Full implementation of the OMG CORBA 1.1 Object Request Broker. Also DOMF.
  1049.    Hewlett-Packard
  1050.    Distributed Computing Group
  1051.    19447 Pruneridge Avenue
  1052.    Cupertino, CA 95014-9974 (USA)
  1053.    Ian Fuller ian@cup.hp.com (408) 447-4722
  1054.  
  1055. > HyperDesk (Westborough MA) HD-DOMS, joe_cordo@hyperdesk.com
  1056.    Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client
  1057.    API only), NetWare (planned, Novell owns part of HyperDesk).
  1058.  
  1059. > IBM SOM (System Object Model)
  1060.    Available on AIX and OS/2.  See Distributed Computing Monitor, March 93 for
  1061.    a detailed review.
  1062.  
  1063. > ILU (free, see APPENDIX E entry 59)
  1064.    Object RPC compatible with OMG CORBA 1.2 spec (will compile OMG IDL and
  1065.    generate OMG compliant code for OMG-specified languages).
  1066.    parcftp.parc.xerox.com:/pub/ilu/ilu.html
  1067.  
  1068. > IONA Technologies, Dublin Orbix, info@iona.ie
  1069.   First full and complete implementation of OMG's CORBA.
  1070.  
  1071. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  1072.   (1) C++ ORB toolkit consisting of over 300 C++ classes and runtime libraries
  1073.   (2) CORBA 1.1 toolkit
  1074.  
  1075. > ORBELINE - The SMART Object Request Broker - PostModern Computing
  1076.   Complete implementation of CORBA.  Free academic; com. eval licence avail.
  1077.   SunOS 4.x, Solaris 2.3, and OSF/1 versions of ORBeline available; will
  1078.   consider making other platforms available if enough interest. See Appendix E.
  1079.  
  1080. > ROLSCH CONSULTING (RC-ORB)
  1081.   Implements ORB spec, DOS/Windows 3.1, 12 user license: $99.
  1082.   Ref: Datamation, LOOK AHEAD Section, August 1.  German Company.
  1083.  
  1084. > SuiteSoftware (Anaheim CA) SuiteDOME
  1085.     runs on VAX/VMS, Unix, PC
  1086.  
  1087. > Sun DOE
  1088.  
  1089. > Tivoli
  1090.  
  1091. > CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  1092.     The ELECTRA Toolkit (not finished)
  1093.  
  1094.  
  1095. 3.8.6  Implementation Descriptions
  1096. ___________________________________
  1097.  
  1098. The OMG also has a (Corporate) Membership list and "known CORBA supporters"
  1099. list with their info package.
  1100.  
  1101.  
  1102. > The ELECTRA Toolkit
  1103.  
  1104. CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  1105. The ELECTRA Toolkit
  1106.  
  1107. Subject: ORB Implementations
  1108. Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST)
  1109. From: Silvano Maffeis <maffeis@ifi.unizh.ch>
  1110.  
  1111.   something like an Object Broker, but it is *not* CORBA compatible (yet).
  1112.   Electra is a research project and not available yet.
  1113.  
  1114.   Its a toolkit for building failure resilient, distributed applications
  1115.   in C++. It supports object-groups, virtual synchrony, multithreading
  1116.   etc. Electra is based on the HORUS toolkit (which is "the new ISIS
  1117.   implementation" developed at Cornell, Ithaca NY.)
  1118.   An overview paper to electra is available from:
  1119.   ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z
  1120.  
  1121.  
  1122. > HD_DOMS
  1123.  
  1124. HD-DOMS (HyperDesk Distributed Object Management System).  A
  1125. CORBA-compliant DOMS.  Includes a GUI API driver for prototyping and
  1126. exercising objects, a bundled object database for persistent object
  1127. storage, a Kerberos-based authentication service, a location service, a
  1128. set of base classes to speed development, and a test script language.
  1129. Revision 1.0 has been shipping since beginning of '92.  Revision 1.1
  1130. (which includes support for CORBA's static client interface) is available
  1131. now, and a NetWare version is in the works.  Submitted a C++ language
  1132. mapping for IDL to the OMG recently.
  1133.  
  1134. HyperDesk Corporation
  1135. 2000 West Park Drive
  1136. Westboro, MA 01581
  1137. (508)366-5050
  1138.  
  1139.  
  1140. > HP ORB Plus and HP Distributed Smalltalk
  1141.  
  1142.   ============================================================================
  1143.   SUBJECT:  HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING
  1144.             SCALABLE, OBJECT-ORIENTED APPLICATIONS
  1145.   DATE:     September 27, 1993
  1146.   ----------------------------------------------------------------------------
  1147.  
  1148.    PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company
  1149.  today introduced a distributed-computing solution for building scalable,
  1150.  object-oriented applications.
  1151.  
  1152.    With HP ORB Plus, programmers can develop scalable, object-based
  1153.  applications that can be distributed throughout the enterprise.  HP also
  1154.  introduced an enhanced version of HP Distributed Smalltalk.
  1155.  
  1156.    HP ORB Plus and HP Distributed Smalltalk are major components of HP's
  1157.  overall distributed-computing strategy, which is designed to give customers
  1158.  integrated, desktop access to enterprise-wide information and resources in
  1159.  distributed heterogeneous systems environments.  Of all computer companies,
  1160.  HP believes it is best positioned to help customers take advantage of
  1161.  distributed computing. HP provides a wide variety of distributed-computing
  1162.  products, understands how to help customers adopt new technology for maximum
  1163.  business benefit, and offers worldwide support and training programs,
  1164.  ranging from analysis and design to deployment.
  1165.  
  1166.    HP ORB PLUS:  CORBA AND DCE COMBINED
  1167.  
  1168.    HP ORB Plus is the only environment that combines the complete CORBA 1.1
  1169.  specification from the Object Management Group with the DCE standard from
  1170.  the Open Software Foundation(tm) as its transport mechanism.  DCE is
  1171.  designed to let developers write one application and then deploy it --
  1172.  without modification -- on any other system that supports DCE.  HP ORB Plus
  1173.  reduces the complexity of developing distributed applications so programmers
  1174.  can concentrate on the application itself without needing to know multiple
  1175.  operating systems, networking protocols or where application objects are
  1176.  stored.
  1177.  
  1178.    The DCE (Distributed Computing Environment) standard provides an
  1179.  integrated set of services that can be used separately or together to
  1180.  provide a distributed computing environment that's easy to administer.  The
  1181.  CORBA (common-object-request-broker architecture) specification provides a
  1182.  standard for how objects (in applications, repositories or class libraries)
  1183.  make requests and receive responses across a distributed network.
  1184.  
  1185.    HP ORB PLUS DETAILS
  1186.  
  1187.    HP ORB Plus consists of several components: the Distributed Object
  1188.  Management Facility (DOMF), object services, developers' and administrative
  1189.  tools, and sample applications.  HP's DOMF provides a location-transparent
  1190.  object-communication mechanism across heterogeneous networks by using the
  1191.  DCE standard.  This object- enabling technology specification was jointly
  1192.  developed with SunSoft. By following a common specification, HP and SunSoft
  1193.  have made it easier for their customers to port applications between their
  1194.  platforms.
  1195.  
  1196.    In addition, HP is working with IBM to integrate HP's DOMF with IBM's
  1197.  System Object Model with extensions for distribution.  This integration will
  1198.  eventually provide users with complete scalability, portability and
  1199.  interoperability of distributed applications across HP and IBM platforms.
  1200.  This is part of the companies' planned approach toward a standards-based,
  1201.  "plug-and-play"  object-oriented environment.  This will give developers,
  1202.  system administrators and end users language-neutral, enterprise-wide,
  1203.  heterogeneous support for building, managing and using distributed object-
  1204.  oriented applications.
  1205.  
  1206.    "We're so convinced of the value of object technology that we're staking
  1207.  our entire company on it,"  said Richard Tanler, president and chief
  1208.  executive officer of Information Advantage, Inc.  "Our object-based
  1209.  applications for retailers provide the means to a competitive business edge.
  1210.  We plan to use HP ORB Plus to develop new object-based products that
  1211.  retailers can distribute to end users throughout headquarters, all chain
  1212.  stores, and warehousing and distribution operations."
  1213.  
  1214.    HP DISTRIBUTED SMALLTALK 2.0
  1215.  
  1216.    In a related announcement, HP introduced Version 2.0 of HP Distributed
  1217.  Smalltalk.  This toolset works with VisualWorks from ParcPlace Systems to
  1218.  provide programmers with a rapid development environment for creating and
  1219.  running distributed applications.  These applications can use object
  1220.  databases (currently OpenODB from HP and Gemstone from Servio) as their
  1221.  storage mechanism to facilitate the reuse of objects.
  1222.  
  1223.    Applications built using HP Distributed Smalltalk currently run without
  1224.  modification on HP, Sun and IBM UNIX(R) system-based workstations.  They
  1225.  also will run on Apple Macintosh computers and on any PC running the Windows
  1226.  3.1 or Windows NT operating systems from Microsoft(R) Corp., once
  1227.  VisualWorks 2.0 is released (expected within two months.)
  1228.  
  1229.    New HP Distributed Smalltalk 2.0 features include the following:
  1230.  
  1231.    --  easier deployment, with the ability to run multiple HP
  1232.        Distributed Smalltalk-based applications on a single system;
  1233.    --  up to 400 percent increased performance, through quicker
  1234.        sending and receiving of remote messages, and reusable
  1235.        object libraries;
  1236.    --  run-time version, for full production deployment; and
  1237.    --  easier development, with remote object browsing so
  1238.        developers can find and use objects more quickly.
  1239.  
  1240.    TECHNICAL DETAILS AND AVAILABILITY
  1241.  
  1242.    HP's DOMF includes the object request broker, interface- definition-
  1243.  language compiler, static and dynamic invocation interface and interface
  1244.  repository.  In addition to these OMG-specific features, most developers
  1245.  writing distributed, object-oriented applications require additional
  1246.  interfaces to use objects effectively.  So developers don't need to create
  1247.  their own, HP has supplied several object-service interfaces for developers
  1248.  to use. That's why HP ORB Plus includes OMG interfaces and implementations
  1249.  for properties, life cycle, associations, event notification and naming.
  1250.  
  1251.    HP's limited release of HP ORB Plus to key developers is designed so that
  1252.  customer input can be incorporated into the product early in its development
  1253.  cycle.  The initial version will work with the C++ programming language.
  1254.  For the generally available Developer's Kit, C++, C and Smalltalk
  1255.  interoperability is planned so objects written in different languages can be
  1256.  combined into one application.  The Developer's Kit is scheduled to be
  1257.  available mid- 1994; prices will be announced then.  HP ORB Plus runs on the
  1258.  HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business
  1259.  servers.
  1260.  
  1261.    Hewlett-Packard Company is an international manufacturer of measurement
  1262.  and computation products and systems recognized for excellence in quality
  1263.  and support.  The company's products and services are used in industry,
  1264.  business, engineering, science, medicine and education in approximately 110
  1265.  countries.  HP has 94,900 employees and had revenue of $16.4 billion in its
  1266.  1992 fiscal year.
  1267.  
  1268.  EDITORIAL CONTACTS:
  1269.     Hewlett-Packard Company
  1270.     Lynne Hanson, 408/447-1415, Cupertino, Calif.
  1271.     Jill Kramer, 408/447-4275, Cupertino, Calif.
  1272.  
  1273.  ==================
  1274.    For more information about HP ORB Plus, contact Kathy Litch
  1275.    (litch_k@apollo.hp.com).
  1276.  
  1277.    For more information about HP Distributed SmallTalk, contact
  1278.    Jerry Boortz (jerry_boortz@hp4000.desk.hp.com).
  1279.  
  1280.  
  1281. > Iris RDOM
  1282.  
  1283. From: rcbc@cs.cornell.edu (Robert Cooper)
  1284. Subject: Re: DCE vs. CORBA
  1285. Reply-To: rcbc@isis.com
  1286. Product: Isis Reliable Distributed Object Manager(tm) (RDOM)
  1287. Company: Isis Distributed Systems, Inc., Ithaca NY, USA.
  1288.  
  1289. Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable
  1290. multi-lingual object-oriented applications. RDOM provides an "object group"
  1291. paradigm for constructing complex applications out of collections of
  1292. cooperating objects. RDOM is built on top of the Isis Distributed
  1293. Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace),
  1294. Objective-C, and C++, and runs on most Unix workstations. RDOM is currently
  1295. not CORBA compliant, but will be brought to compliance during 3Q93.
  1296.  
  1297. Status: 
  1298.  
  1299. RDOM has been at beta test sites since January. General release of
  1300. the Smalltalk and Objective-C language interfaces is expected in June.
  1301. The C++ interface in August. Customers include AMD, Consilium and Swiss
  1302. Bank Corp).  
  1303.  
  1304.